Computer science seeks to simplify the complexity of converting programming goals to functioning software. This has led the development of many high level computer languages and programming paradigms.
A recent approach to programming business related software is premised on modelling the software based on a model of the business procedure on which the software is based. The business procedure is modelled as a set of one or more linked processes or activities that collectively realize the business goal, normally within the context of an organizational structure defining functional roles and relationships. A flow defines the interaction of the processes. During this flow, documents, information, or tasks are passed from one process to another for action, according to a set of procedural rules. For example, considering a credit card application, hiring a new employee, and submitting a loan application may all be so modelled.
Newer high level computer programming paradigms allow the corresponding business related software program to be modelled as the automation of the modelled business procedure, including a well-defined flow of processes. Each process contributes in the solution of the problem, and is treated as a black box. Data is passed between processes; execution of the processes is asynchronous.
One such described computer programming paradigm that facilitates flow programming is referred to as “Workflow Modelling”. More information about Workflow Modelling and flow programming may be gleaned from Business Process Reengineering and Beyond, IBM Redbook SG24-2590-00; Workflow Handbook 1997, John Wiley & Sons, published in association with the Workflow Management Coalition, edited by Peter Lawrence; Improving Performance: How to Manage the White Space on the Organization Chart, by Geary A. Rummler and Alan P. Brache, Second Edition, Jossey-Bass Inc., 1995; Production Workflow: Concepts and Techniques, by Frank Leymann and Dieter Roller, Prentice Hall, 2000; and Process Innovation: Reengineering work through Information Technology, by Thomas H. Davenport, Harvard Business School Press, 1993.
Conveniently, programming tools facilitating flow programming allow a programmer to represent flows as a connected series of processes. Interconnection between the processes represents the exchange of information between the processes. Once the flow is modelled, each process may be implemented in a conventional manner. Each process may, for example, be programmed using a higher level language like Java, C++, Perl, or the like, or may be performed using existing applications having a defined interface. For example, the function of certain processes may be provided by remote web servers using conventional web interfaces like CGI scripts or the like. As well, flow programming allows individual process to execute on different hardware and software platforms that may physically remote from each other. Upon execution, a run-time environment (including run-time code) acts as a flow engine and ensures co-operation between processes in accordance with the flow model. The run-time code typically looks after process execution; inter-process communication; errors; system crashes and the like. Conveniently, programmers and architects need not be concerned about these details as they are handled by run time code.
Known flow based programming environments includes IBM's MQSeries (now IBM's WebSphere); FlexFlow; and Tibco BusinessWorks, available from Tibco Software Inc.
Debugging applications created using the flow programming paradigm presents multiple challenges. For example, debugging should allow meaningful debugging of asynchronous processes and take into account their distributed nature. As well, debugging should be intelligible in light of the underlying flow model used to create the application being debugged.
Clearly then, there is a need for a debugger for debugging applications created using a flow model.